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ABSTRACT 


The  design  for  the  relational  associative  processor 
RAP--a  non-numeric  processor  for  supporting  data  base 
managemen t--is  presented.  It  is  based  on  a  rotating  bulk 
memory  and  combines  the  features  of  associative  and  array 
processors.  This  design  is  aimed  at  storing  a  logical  data 
structure  directly  and  thus  eliminating  most  of  the 
auxiliary  data  structures  of  conventional  data  base 
management  software  and  their  associated  operations  and 
maintenance.  RAP  is  capable  of  executing  high  level 
instructions  on  its  stored  data  directly,  without  the  use  of 
external  data  and  control,  within  on-line  response  times. 
The  data  structure  and  instruction  primitives  are 
particularly  well  suited  for  supporting  the  relational  model 
of  lata. They  can  be  combined  to  form  the  constructs  of 
relational  languages  that  have  been  proven  to  be  at  least  as 
powerful  as  the  relational  calculus  with  respect  to  query 


formulation. 
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INTRODUCTION 


1.1  History  of  DBMS  design  and  its  problems 

The  evolution  of  data  base  management  systems  (DBMS) 
starts  with  the  earliest  methodology  of  information 
processing.  The  concept  of  information  structure  and  the 
operations  of  retrieval,  update,  insertion,  and  deletion 
were  all  embedded  in  the  body  of  the  user's  particular  logic 
for  a  particular  storage  structure.  This  resulted  in  a  two 
directional  data-program  dependency.  A.  change  on  either  side 
of  the  dependency  resulted  in  rewriting  of  the  program  or 
the  rearrangement  of  the  data. 

The  difficulties  faced  with  the  past  DBMS  methodology 
resulted  in  efforts  to  set  standards  for  DBMS  requirements. 
These  standards  called  for  maximum  possible  data 
independence  which  meant  the  separation  of  logical 
information  structure  from  its  physical  representation. 
Currently,  this  requirement  has  to  be  realized  in  the 
environment  of  conventional  Von  Neumann  architecture. 

The  necessity  of  making  the  logical  view  and  the 
physical  representation  of  data  distinct  from  each  other 
created  the  need  for  several  levels  of  indirection  for 
mapping  one  structure  into  the  other.  Also,  efficient 
search  mechanisms  are  needed  to  handle  large  data  bases 
within  concurrent  processing  and  on-line  response  limits. 
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The  implementation  of  these  requirements  resulted  in 
software  complexities  in  the  following  way.  Mechanisms  for 
mapping  structures  and  providing  fast  access  paths  had  to  be 
implemented  by  extra  software  and  data.  Thus,  pointer 
mechanisms  for  cross  reference  and  inverted  lists  had  to  be 
included  at  varying  complexities.  These  pointers  are  extra 
data  requiring  extra  storage,  access,  and  maintenance. 

1 . 2  Pecent  .approaches  to  hardware  support  for  non-numeric 

processing 

The  limitations  of  conventional  processors  prompted  the 
design  of  unorthodox  architectures  which  could  distribute 
logic  by  using  parallel  hardware  configurations.  The  early 
trends  were  to  use  associative  search  hardware  as  subsystems 
within  the  central  processor  and  the  operations  of  these 
subsystems  were  closely  associated  with  the  operations  of 
the  central  processor.1  Subsystems  used  for  memory  page 
searching  and  cache  memories  can  be  given  as  examples.  These 
systems,  however,  were  restricted  to  small  sizes  because  of 
their  high  cost.  It  is  also  evident  that,  with  the  present 
technology  and  the  foreseeable  future,  it  will  not  be 
feasible  to  build  large  scale  pure  associative  memories  as 
required  by  DBMS. 

The  desirable  features  sought  in  DBMS  environment  are: 
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a)  A  large  capacity  and  modular  storage  medium 
with  low  cost  per  bit, 

b)  Ability  to  directly  map  logical  data 
structures  into  physical  data  structures  without 
using  auxiliary  structures, 

c)  Variable  length  data  formats, 

d)  Fast  retrieval  suitable  for  on-line  concurrent 
environments. 


e)  Context  (Boolean 

combinations 

of 

content) 

search  operations 

assisted 

by 

total 

associativity. 

f)  Complete  instruction 

sets. 

The  solution  to  the  cost  limitations  of  associative 
memories  in  view  of  the  desirable  features  of  the  DBMS 
environment  was  the  introduction  of  the  idea  of  using 
distributed  logic  in  inexpensive  large  capacity  circulating 
memory  devices.  Slotnick  was  the  first  to  propose  an 
associative  file  processor  using  a  logic  head  per  track 
device.2  Healy  and  Parhami  studied  possible  architectures 
which  combined  logic  with  a  rotating  bulk  memory  to  achieve 
string  and  template  matches  in  a  context  addressed  manner.3 
4  Minsky  proposed  a  scheme  which  involved  an  arrangement  of 
the  key  items  and  data  items  grouped  separately  using  the 
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cylinder  concept  of  a  disk  memory. s  Parker  partially 
designed  a  device  that  combined  each  head  of  a  fixed  head 
rotating  memory  with  a  single  IC  logic  chip.6  The  studies 
mentioned  thus  far  achieve  only  partial  associativity  and 
most  of  the  fundamental  DBMS  operations  had  to  be 
accomplished  by  the  outside  processor.  Su,  Copeland,  and 
Lipovski  were  the  first  to  study  the  design  of  a  cellular 
processor  on  a  rotating  device  to  support  the  general  data 
structures  and  requirements  of  DBMS.7  8  9 

The  overall  design  of  the  data  structure,  instruction 
set,  and  hardware  architecture  for  BAP  is  presented.10  This 
design  has  been  specified  to  the  gate  level.  A  discussion  of 
cost  and  space  estimates  is  presented  in  the  conclusion. 
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2.  OVERVIEW  OF  RAP  ARCHITECTURE 


2 . 1  Basic  organization 

An  overall  configuration  of  an  operational  RAP 
environment  is  given  in  Figure  1.  RAP  is  an  autonomous 
processor  which  communicates  with  an  outside  general 
purpose  computer  (GPC)  only  to  receive  its  data  base 
contents,  to  receive  its  compiled  programs,  and  to  send  back 
the  results  of  a  user's  requests. 

The  design  is  composed  of  a  controller,  an  arithmetic 
set  function  unit,  and  a  parallel  organization  of  cells.  A 
cell  consists  of  a  memory  component  and  a  logic  component. 
The  memory  unit  is  one  track  of  a  rotating  device  such  as  a 
disk,  drum,  circular  shift  register,  etc..  The  logic 
component  is  a  microprocessor  which  acts  as  a  "search 
machine"  on  data,  directs  data  manipulation,  and  performs 
limited  numeric  computations  required  by  data  base 
processing.  The  set  function  unit  is  used  to  combine  cell 
results  to  obtain  a  value  computed  over  the  total  memory 
contents.  The  controller  is  responsible  for  overall 
coordination  and  sends  control  sequences  to  the  cells, 
controls  the  set  function  unit,  and  executes  decision 
commands  and  other  RAP  primitives  that  can  be  accomplished 
directly  in  itself. 
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F IGURE  1_overview  of  RAP  architecture 
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The  logical  RAP  data  structure  is  stored  directly  so 
that  no  transformations  are  required.  Data  base  contents 
are  manipulated  directly  on  their  storage  by  their 
processors.  The  search  criteria  are  transmitted  to  all  of 
the  cells  simultaneously.  It  is  evaluated  as  the  memory 
contents  "pass  by"  and  the  qualified  contents  are 
immediately  manipulated  or  written  out.  Because  the  entire 
memory  is  processed  for  each  instruction,  inverted  lists  and 
other  search  aids  would  not  enhance  processing  speed.  More 
important,  their  absence  necessarily  eliminates  the  overhead 
of  their  maintenance.  Since  RAP  has  a  parallel  organization 
and  its  memory  is  associative,  the  response  time  is  usually 
independent  of  data  base  size  or  content  but  does  depend  on 
query  complexity.  A  query  can  be  made  up  of  one  or  more 
assembler  instructions.  Most  instructions  are  executed 
within  one  rotation  of  the  entire  RAP  memory  contents. 

Since  data  base  management  operates  mostly  in  a 
concurrent  environment,  means  must  be  provided  to  release 
the  device  as  soon  as  possible  from  one  operation  to  start 
another.  It  cannot  tolerate  excessive  delays  or  overhead. 
The  overall  design  philosophy  is  based  on  this  principle. 
There  are  several  hardware  provisions  throughout  the  design 
to  achieve  this  principle. 

2.2  Cell  organization 
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Each  cell  consists  of  a  rotating  memory,  a  buffer,  an 
information  search  and  manipulation  unit  (ISMU) ,  and  an 
arithmetic  logic  unit  (ALU).  The  basic  logic  blocks  are 
displayed  in  Figure  2.  Each  cell  lies  on  a  serial 
communication  path  and  receives  status  signals  from  its 
predecessor  and  sends  signals  to  its  successor.  The  cell 
also  has  connections  for  I/O  and  signals  that  are  exchanged 
with  the  controller  and  set  function  unit. 

2.2.1  Rotating.memory 

Data  is  read  or  written  via  fixed  heads — one  set  for 
each  cell--while  the  memory  rotates  under  these  heads.  It 
takes  one  revolution  of  the  store,  called  a  track,  for  its 
contents  to  be  read  from  one  end  to  the  other.  This  time  is 
called  the  latency. 

RAP  memory  space  is  the  sum  of  the  individual  cell 
tracks.  The  overall  capacity  should  meet  the  requirements  of 
a  large  data  base  which  is  in  the  order  of  108  to  109  bits. 

A  rotating  bulk  memory  with  high  track  capacity  should 
be  selected  to  achieve  low  cost  per  bit  of  storage. 
However,  there  is  an  upper  limit  on  bit  density  since  there 
is  a  processor  associated  with  each  cell.  Equivalently,  we 
require  a  lower  limit  on  bit  time--the  time  between  two 
consecutively  stored  bits.  It  cannot  be  lower  than  a  value 
determined  by  the  speed  of  the  processor  circuits  because 
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data  to  I/O  bus 

CELLi-1  and  cells 


CELLi+1 


FIGURE  2-overview  of  cell  architecture 
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logic  and  data/signal  transmission  must  be  completed  in  the 
time  elapsed  between  two  bits. 

2.2.2  Buffer 

As  the  memory  rotates  under  the  heads,  it  is  read, 
circulated  through  logic,  and  written  back  after  a  time 
delay.  This  delay  is  proportional  to  the  length  of  a  buffer 
placed  between  read  and  write  heads.  This  buffer  has  been 
designed  to  have  a  length  of  1024  bits  which  holds  a 
sufficient  amount  of  data  exposed  to  the  cell  logic  to 
support  the  logical  data  structure. 

2.2.3  Data  structure 

A  general  data  structure  called  RAP  relations  (similar 
to  normalized  relations  as  defined  by  Codd11)  are  stored 
with  respect  to  a  fixed  track  format.  Details  of  the  data 
structure  and  track  format  are  given  in  the  following 
sections.  It  suffices  to  say  that  a  relation  can  be  viewed 
as  a  "table"  of  data  whose  rows  will  make  up  the  blocks  of 
data  stored  on  a  track.  Rows  are  called  tuples  because  they 
represent  an  n-tuple  of  values.  Both  the  ISMU  and  ALO 
circuits  are  designed  to  function  on  variable  length  data 
fields  within  the  data  blocks. 

Contents  of  the  memory  are  composed  of  blocks  of  data 
and/or  garbage.  The  functions  of  storage  allocation  and 
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garbage  collection  are  accomplished  directly  in  the 
hardware.  Each  cell  uses  the  buffer  to  pack  the  data  on  the 
track  towards  the  beginning  of  the  track  by  "short 
circuiting"  unwanted  items.  This  accumulates  the  garbage  at 
the  end  of  the  data.  New  data  is  first  inserted  at  the 
garbage  space  of  related  tracks  and,  if  more  space  is 
required,  a  new  track  is  initialized  and  used  to  store  the 
rest  of  the  data.  Garbage  collection  takes  place  in  parallel 
with  other  operations  without  the  need  of  user  control  or 
intervention. 

2.2.4  Information  search  and  manipulation  unit 

This  unit  is  responsible  for  inter-cell  communication, 
decoding  of  the  commands  sent  from  the  controller, 
evaluation  of  data  search  criteria,  I/O  data  transfers,  and 
control  of  the  ALU  for  data  modifications. 

2.2.5  Arithmetic  logic  unit 

This  unit  contains  a  serial  adder,  multiplier,  control 
counters,  and  logic  for  arithmetic  computations  and 
modifications.  Logic  for  intermediate  set  function 
calculations  (e.g.,  summation,  maximum,  etc.)  are  also 
present. 

2.3  Set  function  unit 
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The  set  function  unit  (SFU)  provides  the  logic  to 
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calculate  the  set  functions  count,  sum,  maximum,  minimum, 
and  average  over  the  entire  cell  memory.  Intermediate 
results  are  stored  in  individual  ALU  registers  of  the  cells. 
Arithmetic  is  accomplished  through  a  serial  adder  and  a 
serial  divider  which  work  on  the  intermediate  results  as 
they  are  collected  from  the  cells.  Also  provided  are 
counters  for  control  sequencing  as  well  as  data  gathering 
from  the  cell  units  and  for  transmitting  the  SFU  result  to 
the  controller. 

2 . 4  Controller 

The  controller  is  responsible  for  the  overall 
coordination  of  the  cell  processors.  It  loads  the  search 
criteria  units  of  ISMUs,  energizes  opcode  and  mode  lines, 
senses  the  end  of  an  operation,  and  repeats  the  cycle  for 
the  next  primitive.  The  micro-orders  cause  stack  buffer 
contents  associated  with  instructions  to  be  popped  off  and 
bussed  onto  cell  lines  during  data  block  gap  intervals.  The 
controller  also  executes  certain  primitives  that  can  be 
accomplished  directly  in  itself  by  making  use  of  the 
contents  of  registers  whose  values  have  been  stored  from 
previous  operations. 

Other  operations,  such  as  data  transfers  to  and  from 
the  GPC ,  parity  bit  generation,  serial-parallel  conversion. 
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and  error  checking  procedures,  which  are  common  routines 
that  exist  in  present  devices,  will  be  incorporated  into  the 
final  design. 

2 . 5  Instruction  set 

The  RAP  instructions  can  be  divided  into  the  following 
major  groups: 

a)  Retrieval  commands, 

b)  Update  commands, 

c)  Set  function  commands, 

d)  Insertion  and  deletion  commands, 

e)  Data  base  creation  and  destruction  commands, 

f)  Decision  and  transfer  commands. 

Each  command  is  formulated  as  an  assembler  language 
instruction  for  the  RAP  machine.  One  assembler  instruction 
is  implemented  as  one  controller  micro-code  sequence  which 
activates  the  hardwired  logic  in  the  cell  circuits.  The 
opcodes  for  each  instruction  will  be  given  followed  by  a 
brief  explanation.  Details  of  the  instructions  can  be  found 
in  chapter  4.  Appendix  B  gives  a  summary  of  instruction 
timings. 

2.5.1  Retrieval  commands 
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These  commands  are  used  in  the  process  of  locating  the 
qualified  rows  of  relations,  and,  if  required,  outputting 
them  to  the  GPC.  The  commands  included  in  this  group  are: 

a)  MARK (<T>) :  Indicates  the  tuples  of  a  relation  which 
satisfy  a  Boolean  condition  on  its  values  by  setting 
"marking"  bits, 

b)  RESET  (<T>)  :  Resets  marks, 

c)  READ:  Transfers  fields  of  data  from  qualified  and/or 
marked  tuples, 

d)  READ_REG :  Transfers  the  contents  of  registers  from 
the  controller, 

e)  CROSS_MARK  (<T>)  :  Marks  a  second  relation  based  on 
the  values  of  a  previously  marked  relation  (i.e.,  a 
hardware  implementation  of  the  implicit  join 
operation) , 

f)  CRS_COND_MARK  ( <T>[  <T*  >  ]) :  A  variation  of  CROSS_MARK; 
used  for  cross  marking  several  relations  into  a  single 
relation, 

g)  GET_FIRST_MARK  (<T>) :  Used  for  queries  which  involve 
the  selection  of  tuples  based  on  values  which  occur  in 
other  tuples  of  the  same  relation  (i.e.,  used  within  a 
program  implementation  of  the  free  variable  and 
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projection  operations) •  It  finds  the  first  marked 
tuple  of  a  relation,  resets  it,  and  takes  the  value  of 
a  domain  from  that  tuple  and  marks  other  tuples  in  the 
same  relation  whose  same  or  another  domain  satisfies  a 
comparison  on  that  value.  It  can  also  store  value 
items  of  a  tuple  into  the  controller  registers  to  be 
used  as  arguments  in  subsequent  operations, 

h)  GET_FIRST :  A  variation  of  GET_EIRST_MARK, 

i)  SAVE:  Stores  values  from  a  single  tuple  into 
controller  registers. 

2.5.2  Update  commands 

These  commands  provide  value  replacement  by  direct 
insertion  or  after  arithmetic  operations.  The  updated  values 
are  written  back  immediately  so  that  a  separate  rewrite 
command  is  not  reguired.  The  commands  in  this  group  are: 

a)  REPLACE  (<T>) :  Replaces  the  value  of  a  field  of  a  set 
of  qualified  tuples  with  a  new  value, 

b)  ADD (<T>) :  Adds  a  value  to  the  contents  of  a  field  of 
a  set  of  qualified  tuples, 

c)  SUB(<T>):  etc., 

d)  MUL  (<T>)  :  etc.. 
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e)  DIV(<T>):  etc.. 


The  optional  marking  capability  of  these  instructions  is 
used  for  recovery  from  device  or  software  crashes.  As  each 
update  takes  place,  the  combinations  of  T-mark  bits  are  set. 
If  a  crash  occurs,  the  operations  can  be  resumed  on  tuples 
with  T-markings  are  still  off. 

2.5.3  Set  function  commands 

These  commands  compute  functions  over  qualified  sets  of 
data.  Similar  to  update  commands  the  memory  contents  are 
evaluated  "in  place"  so  that  transportation  of  large  amounts 
of  data  is  eliminated  for  simple  computations.  The  commands 
included  in  this  group  are: 

a)  SUM:  Sums  the  values  of  a  set  of  qualified  tuples, 

b)  COUNT:  etc., 

c)  AVERAGE :  etc., 

d)  MAX:  etc., 

e)  MIN:  etc.. 

2.5.4  Insertion  and  deletion  commands 

The  commands  are: 

a)  INSERT:  Inserts  a  new  tuple  into  a  relation. 
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b)  DELETE:  Deletes  qualified  tuples  of  a  relation. 


c)  DP.OP_DOMAIN :  Deletes  a  field  from  a  relation. 

2.5.5  Data  base  creation  and  destruction  commands 

The  commands  are: 

a)  CREATE:  Preformats  a  cell  so  that  it  may  be  used  to 
store  and  manipulate  tuples  of  a  relation, 

b)  DESTROY:  Removes  all  formats  and  data  from  a  single 
cell  or  all  cells  containing  data  from  a  specified 
relation. 

2.5.6  Decision  and  transfer  commands 

As  in  any  programming  language,  certain  instructions 
are  required  for  testing  system  indicators,  providing 
conditional  and  unconditional  transfers  within  a  program, 
and  indicating  termination.  The  following  instructions 
provide  these  functions: 

a)  TEST:  Sets  the  contents  of  a  status  register  based 
on  the  contents  of  markings, 

b)  BC:  Transfers  control  to  another  instruction  if  a 
condition  is  met, 

c)  EOQ:  Signals  the  end  of  a  query. 
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2.6  Role  of  the  general  purpose  computer 


A  GPC  to  be  chosen  for  interfacing  with  the  RAP  device 
should  provide  the  following  main  functions: 

a)  Support  a  data  communication  environment  for  users 
with  proper  I/O  facilities, 

b)  Compile  user  queries  expressed  in  a  high  level  query 
language  into  RAP  primitives, 

c)  Transfer  compiled  RAP  primitives  to  the  RAP 
controller  with  associated  data  used  as  operands  in  the 
format  required  by  the  RAP  controller, 

d)  Transfer  data  to  cell  storage  for  data  base  creation 
and  expansion, 

e)  Support  a  concurrent  processing  environment  and 
thereby  administer  scheduling  of  RAP  program  entry 
queues, 

f)  Control  data  base  security  and  integrity, 

g)  Maintain  relation  names,  domain  names,  and  data 
value  encoding  tables. 

This  list  is  not  exhaustive.  The  section  covering 
project  status  will  outline  other  possible  functions  that 
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may  be  delegated  to  the  GPC  for  achieving  an  optimally 
coordinated  DBMS  environment. 
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3.  RAP  DATA  STRUCTURE 


The  data  structure  chosen  for  the  RAP  is  a  modified 
version  of  the  relational  model  introduced  by  Codd.11  This 
model  is  proven  to  be  general  enough  to  build  other  known 
useful  data  structures  and,  more  important,  present  the  same 
information  conveyed  as  other  data  structures  in  a  way  that 
achieves  a  high  degree  of  data  independence. 

3 . 1  R  AP_r  elat  ional_st  ruct  ure 

A  relation,  as  defined  mathematically,  is  a  subset  of 
the  Cartesian  product  of  sets  S1,S2,...,Sp  (not  necessarily 
distinct) .  The  relational  model  of  data  requires  each  set 
Si,  called  a  domain,  to  derive  its  elements  from  a  set  of 
data  values.  Each  element  of  a  relation  is  then  made  up  of  a 
p-tuple,  or  simply  a  tuple  of  values--one  from  each  domain. 
The  variable  p  is  called  the  degree  of  a  relation. 

A  relation  contains  a  varying  number  of  tuples  and  a 
relational  data  base  contains  several  interrelated  relations 
through  common  domains.  A  relation  is  called  normalized  if 
all  of  its  domains  are  simple,  i.e.,  if  their  elements  are 
single  values.  As  it  can  be  seen  from  the  above  definition, 
the  domains  may  not  be  distinct  in  the  relation.  However, 
each  domain  has  its  distinct  role  in  the  relation  and 
therefore  must  be  uniquely  identified  by  a  unique  domain 
"role  name"  within  a  relation. 
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A  candidate  key  of  a  relation  is  a  minimal  combination 
of  domains  whose  elements  (values)  uniquely  identify  every 
tuple  in  that  relation,  A  primary  key  is  one  of  the 
candidate  keys  with  which  the  unigue  tuple  identification  is 
based  for  implementation. 

We  can  also  view  a  normalized  relation  as  a  table.  The 
table  heading  is  the  relation  name,  the  column  headings  are 
the  domain  names,  and  a  tuple  is  represented  as  a  row. 

A  RAP  relation  is  a  normalized  relation  of  the  type 
described  above  except  that  duplicate  tuples  are  allowed. 
One  restriction  is  that  the  degree  cannot  be  higher  than  a 
number  pmax  depending  on  the  size  of  the  values  of  a  domain. 
This  limitation  is  imposed  by  hardware  considerations.  It 
would  suffice  to  state  here  that  due  to  variable  word  length 
representation  of  RAP  domains,  the  range  for  a  RAP 
relation’s  maximum  degree  is  29  <  pmax  <  100.  We  expect  this 
to  be  sufficiently  high  enough  for  most  applications.  If 
this  is  not  the  case,  then  two  or  more  relations  can  be  made 
from  the  larger  one.  This  is  accomplished  by  partitioning 
the  domains  and  repeating  the  primary  key  with  each 
subrelation.  This  division  can  be  made  in  a  suboptimal  way 
if  a  user  profile  is  known.12 

3.2  Track  format 
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Since  RAP  eliminates  intermediate  mapping  structures,  a 
method  of  representing  the  data  structure  directly  on  the 
storage  had  to  be  found.  Due  to  the  linear  nature  of  a 
memory  track,  a  direct  mapping  of  data  structure  would 
require  it  to  be  linearized.  The  relational  structure  lends 
itself  to  linear  form  easily  as  shown  in  Figure  3.  The 
tuples  of  the  relation,  which  are  themselves  are  linear 
representations  of  domain  values,  can  be  stored  one  after 
the  other  on  a  track.  This  structure  is  similar  to  a  file 
on  a  conventional  disk.  The  first  two  data  blocks  contain 
relation  and  domain  names  respectively  and  act  as  "header" 
blocks.  Each  succeeding  block  contains  the  concatenated 
value  items  in  a  tuple.  The  order  of  domain  names  determines 
the  order  of  the  values  in  each  tuple.  If  a  relation  has  too 
many  tuples  to  be  stored  on  one  track,  then  several  cell 
tracks  are  used.  The  hardware  requires  the  relation  and 
domain  names  to  be  repeated  once  on  each  track  of  a  relation 
and  that  no  cell  can  have  tuples  from  more  than  one 
relation . 

All  names,  values,  and  delimiters  are  items  of  encoded 
bit  patterns.  The  relation  name  block  is  made  up  of  one 
fixed  length  item.  Domain  and  tuple  blocks  can  have  a 
variable  number  of  items  in  different  relations  but  not 
within  the  same  relation.  The  end  of  these  blocks  is 
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indicated  by  a  delimiter  item  (DL) .  Blocks  are  separated  by 
fixed  length  interrecord  gaps.  The  beginning  of  a  track  is 
indicated  by  a  marker  which  is  detected  electronically.  This 
marker  also  implies  the  physical  end  of  a  track.  The  logical 
end  of  a  track  is  indicated  by  a  tuple  block  which  carries  a 
delimiting  "track  end"  (TKE)  item  stored  in  the  first  value 
item's  position.  Items  that  make  up  domain  and  value  blocks 
can  also  be  variable  length.  However,  these  lengths  must 
either  be  32,  16,  or  8  bit  encodings.  Each  item  is  preceeded 
by  a  two  bit  code  to  indicate  the  item’s  length.  The  forth 
code  is  used  to  specify  DL  or  TKE  items  which  are 
distinguished  from  each  other  by  the  following  bit.  There  is 
an  upper  bound  on  the  length  of  a  RAP  relation  tuple  which 
is  determined  by  the  length  of  the  cell  buffer  (1024  bits). 

Tracks  for  a  relation  are  allocated  one  track  at  a  time 
as  needed.  Relation  tracks  are  not  required  to  follow 
sequential  or  contiguous  track  addresses  since  each  relation 
track  is  identified  separately.  This  results  in  different 
relation  tracks  intermixed  with  each  other.  By  making  each 
track  a  separate  entity  by  itself  and  spreading  the 
relations  across  noncontiguous  cells,  output  efficiency  is 
greatly  increased.  This  is  because  several  contiguous  tracks 
are  serviced  as  one  channel  group.  Output  occurs  from  one 
qualified  cell  in  each  channel  cell  group  and  outputs  from 
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these  groups  are  interleaved  to  achieve  a  piped 
transmission. 

There  are  five  control  bit  positions  at  the  beginning 
of  each  tuple.  The  first  bit  is  the  delete  flag  (DF) .  If 
this  bit  is  on,  it  indicates  that  tuple  is  deleted  and 
garbage  collection  hardware  can  ’'erase'*  the  tuple.  Garbage 
collection  on  each  track  is  handled  dynamically.  The  data  is 
packed  towards  the  beginning  of  a  track.  In  case  of 
insertions,  all  of  the  relation  tracks  are  examined  and 
their  available  garbage  tuples  are  filled  with  incoming 
tuples.  If  still  more  insertions  are  to  be  made,  a  new  cell 
and  its  relation  track  can  be  allocated  automatically. 

The  A,  B,  C,  and  D  are  mark  positions  composed  of  one 
bit  each.  If  a  tuple  is  T-marked,  T  being  any  combination  of 
these  4  bits,  the  corresponding  mark  bits  are  turned  on. 
Likewise,  a  tuple  is  said  to  be  T-unmarked  if  the  T 
combination  of  bits  are  turned  off.  There  are  several 
instructions  for  marking  tuples  and/or  using  the  markings  as 
extra  data  values  for  gualifying  sets  of  tuples.  These  bits 
allow  the  results  of  one  instruction  to  be  used  by  another. 
This  greatly  extends  the  associative  capability  of  RAP. 

A  fixed  length  gap  is  required  between  every  two 
blocks.  The  lengths  of  these  gaps  are  proportional  to  the 
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amount  and  speed  of  logic  required  between  block  operations. 
These  gaps  are  grouped  into  the  following  types: 

a)  GAP  1:  This  the  gap  from  track  beginning  (or  ending) 
marker  to  the  beginning  of  the  relation  name  block, 

b)  GAP  2:  This  is  the  gap  between  relation  name  and  and 
domain  name  blocks, 

c)  GAP  3:  This  is  the  gap  between  domain  name  and  first 
tuple  block  and  also  the  gap  between  any  two  tuple 
blocks.  Also,  the  last  tuple  block  is  separated  from 
the  marker  with  this  gap. 

Preformatting  of  a  track  involves  writing  of  all  the 
control  information  of  the  block  types  on  a  track  and 
separating  the  blocks  by  gaps.  Relation  and  domain  blocks 
must  be  filled  in  by  their  names.  Tuple  blocks  are  written 
until  the  physical  end  of  the  track.  Their  DL  identifiers 
and  the  length  codes  in  the  first  two  bit  positions  of  each 
item  must  also  be  filled  in.  The  data  portion  of  value  items 
do  not  contain  any  information  at  that  time.  The  logical 
track  end  is  indicated  by  writing  the  identifier  TKE  in  the 
first  value  item  position  of  the  very  first  tuple  block. 
The  first  value  item  position  of  each  tuple  block  starts  at 
the  sixth  bit  position  leaving  room  for  the  delete  flag  and 
mark  bit  positions.  Care  is  taken  to  make  all  of  these  five 
bit  positions  zero  while  preformatting  each  tuple  block. 
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3 . 3  Data  types 

The  items  stored  as  values  in  the  tuple  blocks  are  of 
two  types:  numeric  and  non-numeric. 

Numeric  items  are  only  integer  values  coded  in  binary 
format.  They  may  be  quarterword  (QW) ,  halfword  (HW) ,  or 
fullword  (FW)  in  length  where  a  FW  is  32  bits.  Two's 
complement  notation  is  used.  That  is  the  leftmost  bit  of 
each  word  indicates  the  sign  of  the  integer  but  is  also  a 
part  of  the  value  represented  by  that  word.  An  integer  is 
positive  if  this  sign  bit  is  0  and  negative  if  this  bit  is 
1. 


Non-numeric  items  are  strings  of  alphameric  characters. 
These  are  the  values  of  non-numeric  domains  of  a  relation  or 
are  domain  names  themselves.  Because  of  coding  schemes  used 
by  various  GPC's  and  because  of  the  need  for  data 
compression,  character  strings  are  encoded  as  bit  strings 
and  are  stored  in  value  items  which  can  be  QW,  HW,  or  FW 
long.  Any  one  of  many  conventional  systems  for  character 
encoding  may  be  used.  Besides  compression,  encoding 
provides  a  form  of  security.  The  burden  for  encoding  and 
decoding  is  placed  on  the  GPC  support  system. 

The  variable  word  length  format  provides  considerable 
flexibility  for  the  encoding  of  character  strings.  The  only 
important  consideration  in  the  encoding  of  non-numeric  items 
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is  that  they  should  reflect  lexicographic  ordering  of  the 
original  character  string. 


33 


4. 


RAP  INSTRUCTION  SET 


4 . 1  Basic  relational  operations 

The  RAP  instruction  set  is  designed  to  construct  the 
basic  operations  necessary  to  support  relational  data  bases 
and,  and  at  the  same  time,  to  be  feasible  for  hardware 
implementation. 

These  basic  operations  are: 

a)  Selection, 

b)  Implicit  join, 

c)  Set  operations, 

d)  Projection, 

e)  Free  variables, 

f)  Arithmetic  set  funtions, 

g)  Simple  arithmetic  update. 

Selection  is  performed  by  applying  a  Boolean  search 
predicate  to  each  tuple  of  a  relation  and  ’'marking"  or 
reading  the  tuples  satisfying  the  predicate.  The  implicit 
join  operation  allows  values  retrieved  from  one  relation  to 
be  used  as  the  retrieval  criterion  on  another  relation.  The 
association  is  made  through  domains  common  to  both 
relations.  The  set  operations  of  union,  intersection, 
complement,  and  difference  can  be  done  on  the  selected 
subsets  of  a  relation.  Projection  is  the  act  of  selecting  a 
subset  of  domains  to  be  retrieved  and  eliminating  duplicate 
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A  "free 


values  after  a  possible  selection  has  occurred, 
variable”  is  the  term  given  to  an  implementation  of  the 
following  capability.13  It  involves  the  selection  of  tuples 
based  on  the  values  of  domains  which  occur  in  other  tuples 
of  the  same  relation.  RAP  programs  which  accomplish 
projection  and  free  variables  require  explicit  iteration. 

4 . 2  S tructure  and  operation  of  the  instructions 

Many  RAP  primitives  reflect  in  their  structure  the 
basic  characteristics  of  a  DBMS  query.  These  primitives 
specify  an  operation  to  be  performed,  a  data  specification 
section  indicating  what  data  is  to  be  operated  upon,  and  a 
qualification  section  specifying  what  conditions  must  be  met 
before  the  operation  can  be  fulfilled.  The  general  format  of 
these  primitives  is: 

<LABELXOPCODE>[  < SPECIFICATION :  <QUALIFICATION>  ] 

The  label  is  an  optional  symbolic  address  of  an  instruction. 
The  opcode  specifies  the  operation.  A  specification  has  the 
format : 


RN  (DN 1  ,  DN  2  ,  ...,  DNK) 

where  RN  is  a  relation  name  and  DN1,  DN2,  .  ..,  DNK  is  an 
optional  domain  list.  There  is  a  hardware  limit  k  on  the 
number  of  K  domains  that  can  be  included  for  any 
specification.  A  qualification  is  a  Boolean  expression  of 
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conditions  on  the  values  of  the  domains  of  a  relation  and  on 
the  mark  bit  values  of  the  tuples  in  which  the  domain  values 
are  stored.  It  can  take  one  of  the  following  forms: 

a)  Null  (a  qualification  which  does  not  specify  any 
condition) ,  every  tuple  of  the  relation  is  considered 
to  satisfy  the  qualification , 

b)  Q1  a  Q2  a  ...  a  QK,  denoting  conjunction, 

c)  Q 1  v  Q2  v  ...  v  QK,  denoting  disjunction, 

where  K  must  be  less  than  or  equal  to  k-- the  hardware  limit 
of  the  number  of  parallel  comparators — and  Qi  is  one  of  the 
following : 

1)  <RN>. <DN>  <COMPARATOR>  <OPERAND>, 

-  where  DN  is  a  domain  name  in  relation  RN, 

-  COMPARATOR  is  one  of  =,  <,  <,  >,  >, 

-  OPERAND  is  one  of: 

.  <REG>  (a  register)  , 

.  integer, 

.  literal  (characters  bounded  by 

quotation  marks)  , 

.  a  GPC  program  variable  name 

(enclosed  in  parentheses) , 

2)  RN.MKED(T), 

3)  RN.UNMKED  (T)  , 
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where  T  is  replaced  by  one  of  the  following  mark 
bit  combinations: 

A,  B,  C,  D,  AB,  AC,  AD,  BC,  CD,  ABC,  ABD , 
BCD,  ABCD. 

Permutations  are  considered  to  be  identical. 
Consider  the  following  example.  Assume  a  ternary  RAP 
relation  EMPLOYEE  with  domains  NAME,  NCHILDREN ,  and  SALARY 
and  further  assume  that  one  of  its  tuples  is  stored  in  track 
format  with  the  values  shown  below. 

a)  DF=0 
A=  1 
B=0 
C=  1 
D=0 

b)  NAME  =  "CLARK" 

c)  NCHILDREN  =  3 

d)  SALARY  =  9500 

Some  of  the  qualifications  that  this  specific  tuple 
satisfies  are: 

a)  NULL 

b)  EMPLOYEE. MKED (A) 

C)  EMPLOYEE. UNMKED (BD) 

d)  (EMPLOYEE. NAME  =  'CLARK')  a  (EMPLOYEE. MKED (AC) ) 
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e)  (EMPLOYEE. NCHILDREN  *  5)  v  (EMPLOYEE. SALARY  >  5000) 
V  (EMPLOYEE. MKED(A)  ) 

At  this  stage,  even  without  seeing  the  details  of  the 
instructions,  it  is  possible  to  show  how  set  operations  can 
be  implemented  by  using  marking  qualification  logic.  Assume 
that  at  one  instance  tuples  of  a  relation  are  A  and  B-marked 
by  criteria-1  and  criteria-2  respectively.  We  denote  the 


subset  of  tuples 

A-marked 

by  criteria- 1  by  ” 

SETA” 

and 

those 

B-marked  by 

criteria' 

-2  by  ”SETB” . 

The 

follow ing 

qualification  statements 

can  be  written 

for 

the 

set 

operations : 

a)  SETA  n  SETB  (intersection) 
qualification:  RN.MKED(AB) 

b)  SETA  0  SETB  (union) 

qualification:  (RN.MKED(A))  v  (RN.MKED(B)) 

c)  SETA  -  SETB  (difference) 
qualification:  (RN.MKED(A))  a  (RN . UNMKED (B) ) 

d)  -i  SETA  (complement) 
qualification:  RN .UNMKED (A) 
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4.3  Retrieval  commands 


4.3.1  MARK 

The  format  is 

<LABEL>  MARK (<T>)  [  <RN>: <QUALIEICATION>  ] 

This  command  marks  the  qualified  tuples  of  the  relation 
RN.  It  can  turn  more  than  one  bit  on  at  a  time  as  indicated 
by  the  mark  bit  combination  T.  This  command  also  controls 
the  "mark  counters”.  In  each  cell  there  are  four  mark 
counters — one  for  each  mark  bit  type.  This  command 
increments  by  one  the  counters  indicated  by  T  for  each  tuple 
marked  on  a  track. 

This  command  takes  one  revolution  to  be  executed  and, 
within  this  time,  the  entire  RAP  contents  can  be  marked.  It 
should  be  noted  that  the  time  to  locate  the  beginning  of  a 
track  takes  an  average  of  half  a  revolution.  However,  since 
the  previous  instruction  ends  its  execution  at  the  end  of 
the  track,  the  device  will  almost  always  find  itself  ready 
to  execute  the  next  instruction. 

4.3.2  RESET 

The  format  is: 

<LABEL>  RESET  (<T>)  [ <RN> : <QUALIFICATION> ] 
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This  instruction  works  exactly  the  same  way  as  the  MARK 
command  except  that  the  bits  are  reset  and  the  mark  counters 
are  not  changed. 

This  command  is  executed  in  one  revolution . 

4.3.3  READ 

The  format  is: 

<LABEL>  READ  [ <RN>  (DN 1 rDN2 , . . . , DNK)  : <QUALI FICATION > ] 
[  <WORKAREA> ] 

This  instruction  transfers  data  from  the  qualified 
tuples  of  relation  RN  to  the  GPC  storage  address  specified 
by  the  WORKAREA.  Only  the  data  values  from  the  domains  in 
the  specification  list  are  read.  It  should  be  pointed  out 
that  there  are  M  internal  output  channels  serving  RAP — each 
serving  N/M  tracks,  called  a  cell  channel  group,  where  N  is 
the  total  number  of  tracks.  Therefore,  M  tracks  can  be 
serviced  in  a  simultaneous  fashion.  Each  channel  services 
one  eligible  track  at  a  time  and  only  one  tuple  can  enter 
the  internal  I/O  interface;  that  is,  the  "first  qualified 
tuple"  encountered  among  M  parallel  paths  is  sent  out.  This 
configuration  speeds  the  read  operation  in  cases  where  the 
qualified  tuples  are  sparsely  scattered  in  several  relation 
tracks.  At  the  start  of  a  read  operation,  all  of  the 
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channels  are  positioned  at  their  first  tracks.  The  operation 
of  a  read  command  follows: 

a)  If  a  specification  list  is  present,  K  domain  values 
of  a  qualified  tuple  will  be  read  out. 

b)  If  no  specification  list  is  present,  the  entire 
qualified  tuple  will  be  transmitted. 

This  instruction  is  completed  within  a  minimum  of  half 
a  revolution  (on  the  average)  and  a  maximum  of  the  number  of 
eligible  tracks.  The  number  of  revolutions  required  depends 
on  the  severity  of  channel  conflicts.  The  actual  number  will 
usually  be  much  less  than  the  maximum  since  not  all  of  the 
cells  satisfy  the  qualification.  The  irrelevant  cells  are 
skipped  in  GAP1  time. 

4.3.4  READ_REG 

The  format  is: 

<LABEL>  READ_REG  [ <REG>,<REG>, ... ,<REG> ] 

This  instruction  involves  the  reading  out  of  the 
contents  of  registers  located  in  the  controller.  These 
registers  are: 

a)  REGF_ 1 , REGF_2 :  These  registers  hold  the  results  of  sst 
function  commands. 
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b)  REGS:  This  is  a  domain  value  save  register  used 
in  connection  with  the  SAVE  command, 

c)  REGC_ 1 , REGC_2 , REGC_3 :  These  are  also  save  registers 
but  are  used  in  connection  with  the  GET_FIRST__MARK 
or  GET_FIRST  commands. 

This  instruction  is  independent  _of  latency  and  is 
executed  at  random  access  memory  speeds. 

4.3.5  CROSS_MARK 

The  format  is: 

<LABEL>  CROSS_MARK (<T1>)  [  <RN 1 > : <RN1 >. <DN 1 >  <COMP> 
<RN2> . <DN  2> : <RN2> . MKED (<T2>)  ] 

where  T1  and  T2  are  mark  combinations,  RN1  is  a  target 
relation,  RN2  is  a  source  relation,  DN1  and  DN2  are  domain 
names,  and  COMP  is  one  of  =,  *,  <,  <,  >,  or  >.  This 
instruction  simulates  the  join  operation  by  marking  the 
target  relation  from  the  source  relation  with  respect  to  the 
COMP  criteria  between  domains  DN1  and  DN2.  The  associative 
nature  of  the  hardware  relieves  the  difficulty  where  there 
are  several  DN1  tuples  for  one  DN2  tuple.  The  execution  time 
is  the  same  for  marking  one  or  many  target  tuples  per  source 
item. 
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The  working  details  of  this  command  follow.  One  source 
cell  becomes  master  while  all  of  the  target  cells  become 
slaves.  k  domain  values  are  picked  up  at  each  revolution 
from  the  source  and  passed  to  all  of  the  slave  cells  and 
COMP  is  made  known  to  the  slaves  by  the  controller.  Each 
slave  qualification  comparator  receives  one  of  these  k 
values  and  immediately  starts  a  disjunctive  qualification 
evaluation  and  Tl-marks  the  target  relation  tuples.  In  the 
source  cell,  each  time  a  T2-marked  tuple  is  encountered,  its 
specified  domain  value  is  taken  as  one  of  the  k  values,  its 
T2-mark  is  turned  off,  and  its  corresponding  mark  bit  is 
decremented  by  one.  These  operations  continue  with  as  many 
cycles  (revolutions)  on  the  master  cell  as  is  necessary  to 
bring  the  mark  counter  down  to  zero.  When  this  counter 
reaches  zero,  the  T2-mark  Or-rail  bit  of  that  cell  is  turned 
off  and  the  next  T2-marked  cell  of  the  source  relation  is 
given  control  as  the  next  master.  The  same  operations  are 
repeated  for  each  FN1  T2-marked  master  cell.  The  operation 
is  finished  when  the  last  source  cell  relinquishes  control. 
This  is  indicated  by  sensing  the  last  member  of  source 
tracks  indicated  by  the  "marked  track"  communication  chain 
which  uses  the  T2-mark  OR-rail  (i.e.,  rail  is  at  logical 
zero,  hence  no  more  T2-marked  tracks  would  be  left) .  The  Or- 
rail  indicates  the  presence  of  one  or  more  T-marked  tracks 
while  the  communication  chain  scheme  establishes  the 
continuity  of  cells. 
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This  instruction  is  executed  in  (rl  ♦  r2)  revolutions, 
where  rl  =  1  +  NT2/k,  constant  1  being  the  extra  controller 
sequence  revolution  needed  by  this  instruction,  NT2  is  the 
number  of  T2-marked  tuples,  and  r2  is  the  number  of  T2- 
marked  source  tracks,  that  is,  the  number  of  tracks  occupied 
by  NT2  marked  tuples.  r2  then  accounts  for  the  total  number 
of  revolutions  due  to  the  shift  of  the  relative  track 
starting  point  at  each  cycle  when  k  source  domain  values  are 
picked  up. 

4.3.6  CRS_COND_MARK 

The  format  is: 

<LABEL>  CRS_COND_MARK (<T 1>[ <T 1 1 > ])  [ <RN 1 > : <RN 1 >. <D N 1 > 
<COMP>  <RN2>. <DN2>:<RN2>. MKED (<T2>)  ] 

This  command  is  similar  to  the  CROSS_MARK  command.  The 
Tl-marking  specification  requires  the  marks  of  a  previous 
CROSS_MARK  instruction.  The  CRS_COND_MARK  command  resets  the 
T 1  bits  of  the  target  tuples  if  the  qualification  criteria 
is  not  satisfied.  Otherwise,  it  has  no  effect  on  the 
satisfied  tuples  which  were  already  Tl-marked  previously. 
During  the  operation  of  the  instruction,  T11  mark  bit  is 
used  as  a  temporary  area  to  remember  the  initial  Tl-mark 
status  of  the  tuples.  CRS_COND_MARK  sets  T1 1  bit  if  the  T1 
bit  of  a  tuple  was  initially  set.  T11  is  needed  because,  at 
a  later  stage  of  the  operation,  an  intermediately  Tl-reset 
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tuple  might  satisfy  the  "AND"  condition  so  that  its  Tl-mark 
bit  may  be  restored.  During  the  last  revolution  T1l  bits  are 
reset . 

This  instruction  is  used  to  perform  an  "AND"  condition 
between  two  mappings  on  the  same  relation.  This  is  needed 
because  there  are  cases  where  more  than  one  relation  is 
reguired  to  be  cross  marked  into  the  same  target  relation 
and  the  result  satisfying  all  of  these  mappings  is  required. 
Although  it  seems  that  this  can  be  accomplished  by  using 
CROSS_MARK  instruction  for  each  source-target  pair,  this  may 
require  too  many  mark  bits  for  several  source  relations 
unless  two  RESET  instructions  are  used  after  each  CROSS_MARK 
instruction.  Another  requirement  for  additional  mark  bits  is 
the  projection  operation  which  will  be  described  later. 

Consider  the  following  example.  Assume  three  relations: 
LOC,  SALES,  and  CLASS.  CLASS  has  domains  ITEM,  and  TYPE,  LOC 
has  domains  DEPT  and  ELOOR,  and  SALES  has  domains  DEPT, 
ITEM,  and  VOL.  The  following  instructions  accomplish  the 
marking  of  source  relations  CLASS  and  LOC,  then  a  cross 
marking  from  LOC  into  SALES  with  equal  DEPT*s.  This  is 
followed  by  a  CRS_COND_MARK  instruction  which  marks  CLASS 
into  SALES  with  equal  ITEM'S.  The  result  will  be  B-marked 
SALES  tuples  that  show  the  second  floor  departments  that 
sell  items  of  type  A. 
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MARK  (A) 


[10C:L0C. FLOOR  =2] 


MARK  (C) 


[CLASS: CLASS. TYPE  =  'A'] 


CROSS_MAP.K  (B) 


[ SALES: SALES. DEPT  =  LOC. DEPT : LOC . MKE D (A)  ] 


CRS_COND_MARK  (B[  A])  [  SALES  :  SALES  . ITEM  =  CLASS.  ITEM: 


CLASS.  MKED(C)  ] 


CRS_COND_MAR K  instruction  takes  one  extra  revolution 
than  the  CROSS_MARK  instruction. 

4.3.7  GET_FIRST_MARK 

The  format  is: 

<LABEL>  GET_FIRST__MARK  (<T1>)  [  <RN> (<DN 1 >,..., <DNS>)  : 

<RN>. <DN1>  <COMP>  <RN> . <DN2> : <RN> . MKED (<T2>) ] 

where  DN 1  and  DN2  of  the  qualification  refer  to  the  same 
or  different  domains  of  the  relation  RN. 

This  instruction  is  used  in  query  programs  where  a 

"free  variable"  is  needed.  The  instruction  works  in  the 

following  way.  The  relation  RN  is  previously  marked.  Two 
bits  should  be  identically  premarked  if  the  original  marking 
must  be  remembered.  The  first  T2-marked  tuple  of  this 

relation  is  picked  up  and  its  domain  values  in  the 
specification  list  are  taken  and  shifted  into  the  REGC_i 
save  registers  that  are  in  the  controller  in  FIFO  order 
starting  from  DN1.  There  can  be  atmost  three  domains 

specified . 


46 


While  the  saving  operation  is  taking  place,  there  are 
other  operations  being  performed  on  the  same  tuple.  The  T2 
bit  is  turned  off,  its  corresponding  mark  counter  is 
decremented  by  one,  and  the  DN  domain  value  is  passed  into 
the  comparators  of  all  of  the  cells  of  the  same  relation 
including  the  cell  of  the  domain  tuple.  In  this  case,  one 
cell  of  the  relation  takes  the  role  of  master  and  with  the 
switching  of  control,  all  of  the  cells  of  this  same  relation 
including  the  master  cell  serve  as  slaves.  This  master  role 
is  repeated  for  all  the  T2-marked  cells — one  cell  at  a  time. 
The  changing  of  the  cells  is  signalled  by  the  zero  condition 
of  the  T2-mark  counter  and  the  next  T2-marked  relation  track 
is  located  by  the  same  communication  scheme  as  in  the 
CROSS_MARK  instruction.  As  soon  as  the  argument  passed  from 
the  tuple  is  picked  up,  qualification  evaluation  and  T1- 
marking  of  the  qualified  tuples  start.  Any  tuple,  excluding 
the  first  domain  tuple  picked  up,  can  be  eligible  for  T1- 
marking.  The  Tl-marking  per  T2-marked  domain  value  takes  one 
revolution. 

The  end  of  the  instruction  would  seem  to  occur  after 
cross  marking  for  the  first  T2-marked  tuple.  However,  the 
normal  use  of  this  instruction  is  a  program  loop  as  will  be 
seen  in  the  following  example  and  in  the  sample  queries  of 
appendix  A.  In  this  case,  the  operation  continues  until  all 
of  the  T2-marked  tuples  are  taken  by  this  instruction.  Each 
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time  the  first  T2-marked  tuple  of  the  relation  is  picked  up 
(this  tuple  was  the  second  before  the  previous  execution 
which  reset  the  first  one  bringing  the  current  tuple  into 
the  first  position)  the  T2-mark  counter  is  decremented.  When 
the  T2-mark  counter  of  the  cell  reaches  zero,  the  T2-mark 
Or-rail  bit  is  turned  off  and  the  next  cell  is  selected  by 
the  communication  scheme  mentioned  earlier.  These  are  the 
functions  of  instruction  hardware.  However,  in  this 
instruction,  termination  is  controlled  by  the  program  which 
establishes  the  loop  with  respect  to  the  status  of  T2-mark 
Or-rail.  Logical  zero  of  the  Or-rail  status  forces  the  end 
of  the  loop  when  the  BC  (branch  on  condition)  instruction  is 
again  executed. 

The  GET_FIRST_MARK  instruction  is  executed  in  (1  +  r3) 
revolutions, where  r3  is  half  a  revolution  on  the  average  for 
one  execution  of  the  instruction.  If  this  instruction  is 
used  in  an  iterative  program,  r3  becomes  equal  either  to  NO 
which  is  the  number  of  tracks  with  unique  T2-marked  tuples, 
or  to  the  number  of  tracks  with  T2-marked  tuples  depending 
on  the  use  of  the  instruction. 

At  this  point,  it  would  be  difficult  to  give  complete 
programs  where  this  instruction  is  best  illustrated  without 
seeing  the  rest  of  the  instruction  set.  For  the  purposes  of 
an  example,  the  relational  projection  operation  will  be 
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explained  and  programmed  so  that  the  use  of  the  instruction 
can  be  seen. 

Projection  involves  the  removal  of  duplicate  values  of 
a  domain  in  a  marked  relation.  Duplicates  are  caused  as  a 
result  of  some  previous  row  or  column  selection  operation  in 
a  relation  where  a  domain  is  not  a  candidate  key.  Although 
projection  can  be  programmed  in  RAP,  at  times  it  may  be  more 
economical  in  a  multi-user  environment  to  let  the  GPC 
accomplish  it. 

Consider  the  relation  SUPPLY  with  several  domains,  one 
of  which  if  the  domain  SPID  whose  values  are  supplier 
identification  numbers,  and  also  assume  that  this  domain  is 
not  a  candidate  key.  The  following  program  segment  shows  the 
example  projection  of  SUPPLY  relation  on  the  domain  COMP  to 
obtain  the  set  of  suppliers. 

MARK  (AB)  [SUPPLY: . ] 

LI  GET_FIRST_MARK  (C)  [  SUPPLY : SUPPLY . SPI D  =  SUPPLY. SPID: 

SUPPLY.  MKED  (A)  ] 

RESET  (ABC)  [ SUPPLY : SUPPLY. MKED  (ABC)  ] 

(Followed  by  decision  and  transfer  instructions  to 

test  a  mark  rail  and  branch  to  Li  until  no  more 

A-marked  tuples  are  left) . 

Assume  that  Figure  4.1a  represents  the  SUPPLY 
relation--a  data  base  consisting  of  13  tuples.  The  values  of 
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the  domain  SPID  are  shown.  Indicated  on  the  right  of  the 
value  column  are  two  other  columns  showing  the  A  and  B-mark 
bits.  Assume  that  x  represents  marked  tuples  according  to 
some  given  qualification.  The  aim  of  the  projection  is  to 
obtain  unique  values  among  the  B-marked  tuples  by 
eliminating  the  duplications.  Tuples  1,  10,  12,  and  3,  6, 

11,  and  4,  9  are  duplications  of  the  marked  domain  values. 
The  following  sequences  of  steps  show  how  the  duplications 
are  eliminated  by  the  program  so  that  a  marked  set  of  unique 
values  would  be  left  in  the  end.  A  "dash"  is  used  to  signify 
that  a  change  occurred  at  the  mark  bit  position  during  the 
last  operation. 

a)  Pick  one  of  the  mark  bits  as  T2. 

b)  Use  the  GET_FIRST_MARK  instruction  that  gets  the 
first  T2-marked  tuple  and,  using  its  domain  value  as 
argument,  Tl-marks  into  the  same  relation  the 
remaining  T2-marked  tuples  with  matching  values  of 
the  same  domain. 

c)  Reset  the  three  bits  (two  original  plus  T1)  of  the 
tuples  marked  by  (b) . 

d)  Repeat  the  operation  from  (b)  until  all  T2-marked 
tuples  are  handled.  The  final  answer  will  be  the 
tuples  left  with  the  second  original  mark  bit  (the 
one  not  specified  as  T2)  .  The  trace  of  the  above 
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operations  on  the  given  example  data  base  is  shown 
in  Figures  4.1b  -  i. 
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Figure  4.1  -  Example  of  Projection  Using  GET  FIRST_MARK 
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Figure  4.1  (cont'd) 
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4.3.8  GET  FIRST 


The  format  is: 

<LABEL>  GET_FIRST  [ <RN> (DN 1 ,DN2 , . . . , DNS)  : 

<RN>. MKED (<T>)  ] 

The  specifications  are  exactly  the  same  as  in  the 
GET_FIRST_MARK  instruction  for  those  parameters  that  apply 
to  both  with  the  exception  that  the  specification  list  must 
not  be  empty.  The  instruction  is  also  used  in  free  variable 
implementations,  however,  in  this  instruction  there  is  no 
cross  marking  involved.  It  just  gets  and  saves  the  values  of 
the  first  marked  tuple  and  resets  its  T  bit.  GET_FIRST  is 
executed  in  the  same  amount  of  time  as  the  GET_FIRST_MARK 
instruction. 

4.3.9  SAVE 

The  format  is: 

<LABEL>  SAVE  [ <RN> (<DN>)  : <QOALIFICATION> ] 
where  DN  is  a  single  domain  name  which  may  not  be  empty. 

In  this  instruction  a  single  qualified  tuple  is  located 
according  to  the  qualification  and  the  value  of  the  domain 
DN  is  saved  in  register  REGS.  No  marking  is  involved.  This 
instruction  is  executed  in  one  revolution. 

4.4  Update  commands 
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4.4.1  ADD,  SUB,  MUL,  and  DIV 


The  format  is: 

<LABEL>  <OPR>  (T)  [ <RN>  (<DN>)  : <QUALIEICATIO N> ][  <OPD> ] 

where  OPR  is  either  ADD,  SUB,  MUL,  or  DIV,  DN  is  the  name  of 
a  numeric  domain,  OPD  is  any  REG  in  the  controller  or  a 
value  with  the  restriction  that  it  must  be  a  value  in  the 
case  of  divide  (DIV) ,  and  T  is  an  optional  mark  bit 
combination. 

The  instruction  adds,  subtracts,  multiplies,  or  divides 
the  value  of  OPD  to  every  value  stored  in  domain  DN  whose 
tuple  satisfies  the  qualification.  These  instructions  are 
executed  in  one  revolution. 

The  optional  combination  of  T-mark  bits  is  used  where 
recovery  is  necessary  from  device  crashes.  As  each  update 
takes  place,  the  combination  of  T-mark  bits  are  set.  If  a 
crash  occurs,  the  operation  can  be  resumed  on  the  tuples 
whose  mark  bits  are  still  off. 

Negative  numbers  are  represented  in  two's  complement 
form.  Indication  of  overflow  in  ADD  and  SUB  are  signalled 
to  the  controller.  The  result  of  the  multiplication  is  as 
long  as  the  word  length  of  DN.  In  the  case  of  division,  OPD 
should  be  passed  from  the  GPC  in  the  form  of  OPD* = (2**w/0PD) 
in  binary  coded  form  where  w  is  the  number  of  bits  in  an 
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item.  OPD 1  should  be  computed  as  an  integer  value  during  the 
compilation. 

4.4.2  REPLACE 

The  format  is: 

<LABEL>  REPLACE  (T)  [  <RN>  (<DN>)  : <QUALIFICATION>  ][  O PD>  ] 

where  DN  is  domain  name  of  any  domain  and  OPD  is  same  as  in 
section  4.4.1.  OPD  is  entered  into  the  ALU  result  register. 

The  tuples  which  satisfy  the  qualification  are  updated  by 
over-writing  the  value  OPD  onto  the  present  value  of  DN. 

This  instruction  is  executed  in  one  revolution. 

4.5  Set  function  commands 

The  format  is: 

<LABEL>  <SOPR>  [  <RN>  (<DN>)  :  <QUALIFICATION>  ][  <I>  ] 

where  SOPR  is  one  of  the  SUMrCOUNT,  MAX,  MIN,  or  AVERAGE,  DN 
is  the  name  of  a  numeric  domain  which  is  null  for  the  opcode 
COUNT,  and  I  is  an  integer  which  can  be  either  1  or  2 
(default  being  1)  which  specifies  one  of  the  two  registers 
in  the  controller  to  hold  the  final  result.  The  set  function 
SOPR  is  applied  to  all  values  of  domain  DN  whose  tuples 
satisfy  the  qualification.  The  result  is  placed  in 
controller  register  REGF_I . 
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The  operation  of  these  instructions  is  as  follows. 
First,  each  cell  containing  the  relation  computes  the 
specified  function  in  its  ALU,  Next,  by  the  start  of  the 
second  revolution,  the  set  function  unit  serially  polls 
these  ALU's  with  the  help  of  a  function  communication  chain 
and  evaluates  the  same  specified  function  in  its  circuits 
while  the  results  of  ALU's  are  taken  in  one  at  a  time, 

AVERAGE,  unlike  other  primitives,  is  an  assembler  macro 
which  is  broken  down  to  the  following: 

SUM  [ <RN>  (<DN>)  :<QUALIFICATION>] 

COUNT  [  <RN>:<QUALIFICATION>] 

DIV 

This  last  command  is  between  the  controller  and  the  set 
function  unit.  The  operands  are  implicit  (i.e.,  SFU 
registers  are  involved) .  READ_REG  command  should  follow  if 
either  of  the  two  register  contents  are  to  be  output. 

These  function  instructions  take  one  revolution  for 
cell  computations  and  another  fraction  of  a  revolution  for 
final  computation  by  the  SFU.  (This  might  reach  a  full 
revolution  if  most  of  the  cells  are  occupied  by  the  relation 
in  question) .  The  AVERAGE  command,  however,  is  an  exception 
and  takes  twice  as  long  as  other  function  instructions. 

4.6  Insertion  and  deletion  commands 


57 


4.6.1  DELETE 


The  format  is: 

<LABEL>  DELETE  [ <RN> : <QUALIFICATION>  ] 

This  instruction  sets  the  delete  flag  (DF)  of  all  the 
qualified  tuple (s)  of  a  relation  that  are  going  to  be 
deleted  from  the  data  base.  Any  delete  flagged  tuple  is 
ignored  in  future  searches  until  it  is  physically  cleared  by 
the  garbage  collection  hardware.  If  deletion  occurs  on  a 
track,  memory  is  packed  or  moved  one  tuple  towards  the 
beginning  of  the  track  at  each  subsequent  revolution.  The 
garbage  collection  takes  place  while  the  subsequent  tuples 
are  checked  for  DF  flagging.  This  happens  because  one  tuple 
per  track  can  physically  be  deleted  per  revolution  by  the 
hardware.  After  the  end  of  this  instruction,  the  hardware 
continues  to  physically  move  non-deleted  tuples  at  a  rate  of 
one  tuple  per  track  per  revolution.  This  occurs  in  parallel 
with  the  other  operations  that  do  not  involve  the  relation 
whose  tuples  are  deleted.  Every  time  a  tuple  is  physically 
deleted  the  insert  counter  in  each  cell,  showing  the  number 
of  tuples  stored  per  track,  is  decremented  by  one. 

4.6.2  INSERT 

The  format  is: 

<LABEL>  INSERT  [  <RN>  ][  <WORKAREA>  ] 
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where  WORKAREA  is  a  storage  location  in  the  GPC  which 
contains  the  tuple  to  be  inserted. 

As  pointed  out  in  DELETE,  there  is  a  dynamic  garbage 
collection  in  RAP  so  that  several  cells  of  a  relation  might 
have  pools  of  available  memory  space  after  the  logical  end 
of  their  tracks.  Since  the  storage  allocation  is  also 
dynamic  and  handled  by  hardware,  the  available  spaces  are 
automatically  allocated  for  new  data. 

Insertion  works  as  follows.  Assume  that  there  tracks  of 
the  relation  on  the  storage.  First,  the  insert  communication 
chain  is  activated.  The  chain  starts  a  serial  scan  from  the 
lowest  numbered  cell  to  the  higher  ones.  The  search  is  for 
the  first  relation  cell  with  available  space  for  insertions. 
This  indication  is  obtained  by  locating  the  first  cell  with 
its  "insert  counter"  below  the  full  capacity.  The  insert 
counter  counts  the  number  of  tuples  per  track.  If  it  reached 
its  terminal  count,  it  means  that  the  track  is  full.  This 
counter  exists  in  each  track  and  it  is  restored  during  the 
first  revolution  at  device  turn-on  time. 

Once  the  track  is  located,  data  transmission  into  the 
cell  from  the  controller  is  enabled  and  the  tuple  to  be 
inserted  is  written  into  the  preformatted  TKE  tuple  slot. 
When  the  insertion  finishes,  the  next  tuple  written  is  the 
new  TKE  tuple  since  the  old  one  has  overwritten  with  new 
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data.  For  each  tuple  inserted  on  the  track,  the  insert 
counter  is  decremented  by  one. 

If  an  insert  to  the  existing  formatted  tracks  cannot 
take  place,  a  signal  is  given  to  controller  to  start  a 
preformat  operation. 

The  preformat  operation  has  several  phases: 

a)  Locate  the  first  (lowest  numbered)  empty  track, 

b)  Write  relation  name  and  domain  name  blocks 
respectively, 

c)  Repeatedly  copy  the  the  preformat  tuple  from  the 
controller  buffer  store  until  the  track  is  completely 
written, 

c)  While  writing  the  first  preformat  tuple,  ”TKE”  is 
also  stored  in  it  to  indicate  the  logical  track  end. 

After  the  track  is  preformatted  this  way,  the  insert 
operation  is  enabled  and  the  tuple  is  inserted  by  writing  it 
as  before. 

During  the  insert  operation  two  buffers  in  the 
controller  are  used--  they  are  Buffer-1  and  Buffer-2. 
Buffer-2  holds  the  incoming  tuple  to  be  inserted.  Buffer-1 
is  a  one  tuple  long  buffer  area  which  is  set  up  by  the  GPC. 
It  is  used  during  preformatting  operation.  This  area  holds 
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the  preformatted  tuple  and  the  same  content  is  copied  over 
and  over  onto  the  track  to  be  preformatted. 

This  instruction  takes  one  revolution  if  the  data  to  be 
inserted  is  written  into  an  existing  relation  track  which 
has  available  space.  If  preformatting  is  involved,  one 
revolution  for  preformatting  must  be  added  to  the  insertion 
time. 

4.6.3  DR OP_DOMAIN 

The  format  is: 

<LABEL>  DEOP_DOMAIN  [ <RN> (<DN>) : <QUALIFICATION> ] 

where  DN  is  a  single  domain  name.  This  instruction  is 
intended  for  structural  changes.  Its  scope  is  all  the  tuples 
of  the  relation,  however,  the  tuples  must  be  marked  by  a 
previous  mark  instruction.  It  can  delete  only  one  domain  per 
instruction.  One  domain  is  deleted  per  revolution  per  track. 

4 . 7  Data  base  creation  and  destruction  commands 

4.7.1  DESTROY 

The  format  is: 

<LABEL>  DESTROY  [ <RN>  ][ <CELL#> ] 

This  instruction  erases  the  relation  name  block  to 
binary  zeros  of  all  the  tracks  of  relation  RN.  It  also 
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resets  rhe  insert  counters  of  those  tracks.  If  an  optional 
CELL#  is  provided,  only  that  cell  is  removed  from  the 
relation . 

This  instruction  takes  a  fraction  of  a  revolution  to 
execute.  It  is  finished  by  the  time  the  start  of  the  domain 
names  block  is  reached. 

4.7.2  CREATE 

The  format  is: 

< LABEL >  CREATE  [  <RN>  ][  <WORKAREA>  ][  <CELL#>  ] 

This  instruction  is  identical  to  the  preformat  function 
described  earlier,  only  this  time  it  is  directed  externally 
rather  than  as  a  result  of  the  INSERT  instruction.  It  works 
exactly  the  same  as  preformat,  establishing  a  single 
preformatted  track  of  a  new  relation.  If  more  tracks  are  to 
be  preformatted,  several  create  instructions  should  be 
submitted  by  the  GPC.  The  instruction  is  normally  followed 
by  INSERT  if  data  have  to  be  stored  into  the  cells  at  the 
same  time.  If  the  optional  CELL#  is  not  provided,  then  the 
hardware  will  choose  the  first  available  cell. 

This  instruction  takes  one  revolution  for  each  track  to 
be  preformatted. 

4.8  Decision  and  transfer  commands 

4.8.1  TEST 
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The  format  is: 


<LABEL>  TEST  <T>_RAIL 

where  T  is  either  A,  B,  C,  or  D.  This  instruction  is  used  to 
test  the  status  of  any  one  of  the  four  mark  rails  and  places 
the  result  into  the  bit  positions  reserved  in  the  device 
status  register  of  the  controller.  These  bit  positions  are 
referred  as  RAIL__STAT  (<T>)  . 

This  instruction  is  independent  of  latency  and  executed 
in  the  controller  in  less  than  a  microsecond. 

4.8.2  BC 

The  format  is: 

<LABEL>  BC  <ADDRESS>,<CONDITION> 

where  BC  is  the  abbreviation  for  ’’branch  on  condition", 
address  is  any  instruction  label,  and  condition  can  be: 

a)  RAIL_STAT (<T>) 

b)  <REG>  <COMP>  <OPR>  where  OPR  is  a  qualification 
operand 

c)  Null 

This  instruction  evaluates  the  condition  which  can  be 
true  or  false  (binary  one  or  zero  respectively) .  If  the 
result  of  the  condition  is  true,  transfer  is  given  control 
to  the  instruction  whose  label  is  given  by  the  address.  If 
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the  result  is  false,  the  next  instruction  after  the  BC  is 
given  control.  Condition  null  forces  a  true  condition  by 
making  the  BC  instruction  an  unconditional  branch 
instruction.  If  a  mark  rail  tested  has  marked  cells  attached 
to  it,  the  condition  will  be  evaluated  as  true. 

This  instruction  is  independent  of  latency  and  executed 
in  the  controller.  It  stays  "on”  until  the  address  of  the 
next  instruction  is  decoded  which  takes  less  than  a 
microsecond. 

4.8.3  EOQ 

The  format  is: 

<LABEL>  EOQ 

where  EOQ  is  abbreviation  for  ”end  of  guery" .  This 
instruction  signals  the  logical  end  of  a  RAP  program.  After 
the  execution  of  this  instruction,  the  control  is  given  to  a 
new  program. 
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4.9  GPC  and  RAP  communication 


Although  the  load  on  the  GPC  and  the  channel  is 
minimized  compared  to  conventional  systems,  the  following 
information  must  be  exchanged  between  interfacing  units: 

a)  Status  information  to  be  supplied  by  RAP 

1.  Rail-status, 

2.  Arithmetic  error  indication, 

3.  Interrupt  flags, 

4.  Instruction  address, 

5.  BC  test  result, 

6.  Other  information  regarding  device  status 
and  data  transfers. 

b)  Data  transfers  between  GPC  and  RAP 

1.  GPC  sends  RAP  instructions  and  their 
associated  parameter  information, 

2.  GPC  sends  value  sets  for  creating  a  new 
relation  or  extending  an  existing  relation, 

3.  RAP  returns  value  sets  and  associated  status 
information  retrieved  by  the  query  programs. 

The  following  will  give  details  of  these  transfers  listed  in 
(a)  and  (b)  . 
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A  query  program  consists  of  several  RAP  primitives. 
Each  primitive  is  made  up  of  an  operation  code  followed  by 
sequences  of  groups  of  bits  representing  micro-operations. 
These  micro-operations  establish  controller  sequences.  The 
micro-operation  bit  groups,  when  set  on,  cause  related 
parameters  to  be  popped  off  the  controller  stacks  or  shifted 
out  of  buffers  and  routed  onto  the  data  lines  that  supply 
each  cell.  Associated  with  these  activities,  the  GPC 
transfers  the  following  information  to  the  RAP  buffer  and 
stack  store  unit: 

a)  RAP  program  instructions, 

b)  Relation  name  items, 

c)  Domain  name  items, 

d)  Value,  literal,  variable  name  operands, 

e)  For  insertions,  tuples  stored  with  value  items 
according  to  tuple  block  and  item  formats, 

f)  For  preformatting,  relation  name,  domain  names 
block,  and  one  tuple  block  stored  with  value  items 
whose  length  encodings  are  present,  but  value  bit 
positions  empty. 

During  the  assembly  of  RAP  primitives  into  RAP  machine 
code,  register  names  are  translated  into  their  3-bit  address 
codes  or  into  positional  bit  vector  representations.  A 
complete  list  of  registers  is  given  in  the  controller 
hardware.  The  register  REGIM  however,  is  an  exception:  it 


66 


cannot  be  addressed  by  an  instruction.  It  is  used  for 


loading  the  value  of  an  item  of  type  (d)  in  the  list  above, 
referred  in  a  BC  instruction,  during  the  transfer  operations 
of  the  GPC  into  the  RAP. 

A  proper  GPORAP  dialogue  is  currently  being  studied 
which  will  enable  the  transfer  of  information  outlined  in 
this  section  by  using  standard  channel  interface  facilities. 

The  GPC,  therefore,  has  to  assemble  the  RAP  mnemonic 
primitives  into  RAP  machine  code  form,  set  up  the  required 
formats,  and  fill  the  encoded  data  and  the  length  for  the 
items  required  in  (b)  through  (f)  of  the  above  list.  The 
following  tables  should  be  maintained  in  the  GPC  in  order  to 
provide  the  information  needed  in  setting  up  the  contents  of 
each  item  with  respect  to  the  requirements  of  a  specific 
instruction: 

a)  A  table  of  relations  which  should  contain 
for  each  entry: 

1.  Relation  name, 

2.  Pointer  to  encoding  table  or  procedure, 

3.  Security  and  integrity  locks  and/or  masks, 

4.  Number  of  initial  tracks  to  be  preformatted. 

b)  A  table  of  domain  names  which  should  contain 
for  each  entry: 
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1.  Domain  name, 

2.  Pointer  to  encoding  table  or  procedure, 

3.  Security  and  integrity  locks  and/or  masks, 

4.  Data  type, 

5.  Data  length. 

In  addition  to  above  information,  the  GPC  should  provide 
the  following  functions: 

a)  Encoding  and  decoding  procedures, 

b)  Routines  for  converting  other  information 
structures  into  RAP  relations, 

c)  Conversion  from  general  normalized  relations 
into  limited  width  RAP  relations  (if  necessary) , 

d)  Security  and  integrity  procedures. 
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5. 


PROJECT  STATUS 


5 . 1  Cost  and  space  estimates; 

A  preliminary  logic  design  of  the  cell  hardware  has 
been  completed  to  gate  level.  This  design  has  provided 
rough  estimates  for  the  cost  and  space  requirements  of  the 
RAP  hardware.  The  number  of  parallel  comparator  units  k  must 
be  considered  both  in  terms  of  software  implications  and 
hardware  costs.  At  this  stage  an  intuitive  value  of  5 
appears  to  satisfy  a  wide  range  of  software  applications  as 
well  as  cost  effectiveness  criteria. 

A  gate  count  of  1500  for  k=1  and  175  for  each 
additional  unit  of  k  (2200  for  k=5)  per  cell  is  the  space 
requirement  excluding  the  memory  elements  such  as  registers 
and  counters.  The  total  space  per  cell  when  these  memory 
elements  are  included  is  found  to  be  59  MSI  chips  (of  about 
70  gate  complexity)  for  k=1  and  6.5  for  each  additional  unit 
of  k  (85  MSI  chips  for  k=5) .  The  buffer  register  is  excluded 
from  this  count  since  it  is  an  LSI  package.  Register  and 
counter  densities,  however,  are  determined  in  terms  of  their 
package  counts.  The  total  space  and  cost  can  be  reduced  by 
having  made-to-order  LSI  components.  The  power  requirement 
for  a  T2L  implementation  for  k=1  is  about  20  watts  per  cell 
and  2.5  watts  for  each  increment  of  k  (for  k=5  the  power 
requirement  is  30  watts) .  The  costs  of  this  preliminary 
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design  for  the  required  IC  packages  are  estimated  to  be  less 
than  $300  for  k=1  and  $25  for  each  additional  unit  of  k 
(less  than  $400  for  k=5)  per  cell. 


The  controller  circuitry  dealing  with  the  RAP  functions 
is  about  the  size  of  one  cell.  This  excludes  the  read  only 
and  other  buffer  and  stack  memories  as  well  as  the  circuits 
in  the  controller  I/O  function  unit.  We  anticipate  the 
memory  capacity  of  a  cell  to  be  10*  bits.  Thus,  the  hardware 
cost  of  a  RAP  device  (excluding  the  memory)  for  a  108  bit 
data  base  and  with  5  parallel  comparator  units  would  be 
approximately  $40,000.  The  requirement  on  the  cell  memory 
capacity  can  be  somewhat  relaxed  if  the  cost  of  cell 
hardware  can  be  reduced  by  specially  designed  LSI  chips. 
This  would  then  compensate  for  the  extra  cost  of  additional 
cells  needed  to  make  up  the  overall  device  capacity. 


5.2  Feasibility  evaluation  and  software  support 


The  next  step  in  the  RAP  project  will  be  the 
construction  of  a  small  prototype  so  as  to  experiment  with 
hardware  feasibility,  economies,  and  overall  operation.  To 
understand  how  to  best  utilize  and  support  RAP,  the 
following  software  studies  must  be  made: 


a)  Determine  exactly  which  functions  that  are  possible 
in  either  the  GPC  or  in  the  RAP  should  be  solely  or 
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partially  delegated  to  the  GPC  and/or  RAP  for  better 
efficiency  and  under  what  conditions, 

b)  Investigate  whether  the  outcome  of  (a)  implies  a 
reduction  of  RAP  primitives  to  a  more  fundamental  set, 

c)  Investigate  concurrency  for  on-line  processing  and 
the  impact  it  would  have  on  the  operating  system 
reguirements . 

At  this  stage  a  conceptual  RAP  concurrency  model  has 
been  considered  though  not  presented  in  this  report.  This 
model  requires  certain  minor  additions  to  the  hardware  as 
well  as  to  the  software  control.  The  control  functions 
needed  for  software  are  currently  being  studied  and  their 
exact  place  in  the  operating  system  (if  needed  at  all)  as 
well  as  scheduling  and  programming  protocol  have  yet  to  be 
determined . 

5.3  Hardware  disclosure  policy 

The  detailed  specifications  for  cell  hardware,  and 
controller  and  set  function  unit  are  not  included  in  this 
document  and  will  not  be  released  until  questions  of 
proprietary  rights  are  settled.  Those  interested  in  the 
utilization  of  the  design  concepts  should  contact  the 
authors. 
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APPENDIX  A 


SELECTED  SAMPLE  QUERIES 

In  this  section  some  sample  queries  will  be  programmed 
with  the  RAP  instruction  set.  The  samples  are  similar  to 
those  described  in  the  literature  for  languages  SQUARE 1 3 , 
SEQUEL1 4 ,  ALPHA15  which  were  proposed  as  high  level  query 
languages  to  be  used  for  relational  data  bases.  They  have 
been  proven  to  be  complete  in  the  sense  that  they  are  at 
least  as  powerful  with  respect  to  query  formulation  as  the 
relational  calculus.  The  RAP  instruction  set  includes  all 
the  capabilities  of  these  languages.  All  of  the  queries  used 
as  examples  in  the  above  languages  have  been  programmed  in 
RAP. 


The  sample  queries  are  divided  into  two  major  groups; 
those  that  can  be  executed  very  fast  and  those  that  involve 
iterations  either  in  hardware  or  in  the  program.  The 
estimated  number  of  revolutions  for  query  execution  will  be 
given.  The  execution  time  depends  on  the  rotational  speed  of 
the  device.  In  the  hardware  design  means  for  effectively 
reducing  the  device  latency  are  being  considered. 

The  data  base  used  for  the  examples  consists  of  the 
following  relations: 

EMP  (NAME,  DEPT,  MGR,  SAL) 

LOC  (DEPT,  FLOOR) 
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SALES (DEPT,  ITEM,  VOL) 

CLASS (ITEM,  TYPE) 

NEWSALES (DEPT,  ITEM,  VOL) 

where  employee  relation  EMP  has  a  tuple  for  every  employee 
giving  his  name,  department,  manager's  name,  and  salary.  The 
location  relation  LOC  gives  the  floor  on  which  each 
department  is  located,  that  is,  it  has  a  tuple  for  each 
department  floor  pair.  The  SALES  relation  has  a  tuple 
indicating  the  yearly  volume  sold  for  an  item  in  each 
department.  The  relation  CLASS  has  tuples  giving  a  specific 
type  of  an  item  sold  in  the  departments.  The  NEWSALES 
relation  is  a  relation  similar  to  SALES,  it  relates  current 
sales  data  that  has  yet  been  accumulated  into  the  SALES 
relation . 

A .  1  Non-iterative  queries 

Q . 1  Find  the  employee  whose  salary  is  greater  than  that  of 
any  employee  in  the  SHOE  department. 

The  RAP  program  is: 

a)  MAX  [  EMP  (SAL)  :  EMP. DEPT  =  'SHOE'] 

b)  MARK  (A)  [EMP:  EMP.  SAL  >  (REGF_1)  ] 

c)  EOQ 

The  timings  will  be  given  separately  for  each 
instruction  and  the  overall  program  timing  will  be  produced 
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at  the  end.  The  figures  given  with  the  instruction  numbers 
denote  the  number  of  revolutions  required  for  the  execution 
of  the  instruction. 

The  estimated  time  for  the  query  execution  is: 

a)  1  ♦  Fraction  «■  Time  to  synchronize  to  next 
instruction  =  2 

b)  1 

c)  Negligible 

The  time  needed  to  synchronize  to  the  start  of  the  first 
instruction  of  a  program  is  1/2  revolution  on  the  average. 
This  figure  is  added  to  the  overall  program  time , therefore: 

Total  time  =  3.5  revolutions. 

Q.2  List  the  names  and  managers  of  employees  in  the  SHOE 
department  with  salaries  greater  than  10,000. 

The  RAP  program  is: 

a)  READ  [ EMP  (NAME, MGR)  :  (EMP. DEPT  =  •SHOE*) 

(EMP.SAL  >  10000)  ] 

b)  EOQ 

The  estimated  time  for  query  execution  is: 

a)  Minimum  =  1/2,  maximum  =  number  of  tracks 
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of  the  EMP  relation  with  the  qualified  tuples 
b)  Negligible 

Total  time  =  (1/2  ♦  (a))  revolutions,  where  (a) 
specifies  some  average.  The  maximum  will  never  be 
reached  because  of  the  internal  data  path  multiplexing 
scheme  used  in  the  RAP.  However,  for  very  large 
qualifying  sets  of  data,  the  program  should  be 
classified  as  an  iterative  type. 

Q . 3  Move  the  location  of  the  TOY  department  to  the  second 
floor. 

The  RAP  program  is: 

a)  REPLACE  [  LOC  (FLOO  R)  :  LOG.  DEPT  =  ,T0Y,][2] 

b)  EOQ 

The  estimated  time  for  the  query  execution  is: 

a)  1 

b)  Negligible 

Total  time  =  1.5  revolutions. 

Q.4  Delete  from  EMP  all  the  employees  who  work  for 
ANDERSON'S  manager. 

The  FAP  program  is: 

a)  SAVE  [EMP  (MGR)  :EMP. NAME  =  'ANDERSON'] 

b)  DELETE  [  EMP: EMP.  MGR  =  (REGS)  ] 
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c)  EOQ 


The  estimated  time  for  the  query  execution  is: 

a)  1 

b)  1 

c)  Negligible 

Total  time  =  2.5  revolutions. 

Q.5  Add  the  contents  of  the  variable  SOLD  to  the  volume  for 
the  item  SLIPPERS  in  the  SHOE  department. 

The  RAP  program  is: 

a)  ADD  [  SALES  (VOL)  :  (SALES. DEPT  =  'SHOE')a 
(SALES. ITEM  =  'SLIPPERS')  ][  (SOLD)  ] 

b)  EOQ 

The  estimated  time  for  the  query  execution  is: 

a)  1 

b)  Negligible 

Total  time  =  1.5  revolutions. 

Q.6  Delete  all  tuples  of  the  data  base  relation  NEWSALES 
involving  employee  CLARK's  department  and  the  item  SLIPPERS. 

The  RAP  program  is: 

a)  SAVE  [EMP(DEPT)  :EMP.NAME  =  'CLARK'] 

/*  Save  the  department  where  CLARK  is  employeed  */ 
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b)  MARK (A)  [ NEWS ALES : NEW  SALES. DEPT  =  (REGS)] 

/*  Mark  this  department  in  NEWSALES  */ 

C)  RESET  (A)  [NEWSALES:  (NEWSALES. MKED  (A)  )  a  (NEW  SALES  .  ITEM  # 

' SLIPPERS')  ] 

/♦Reset  mark  bits  if  qualifiers  are  not  in  combination*/ 

d)  DELETE  [ NEWSAL ES : NEWSALES . M KED (A)  ] 

/♦Delete  rows  in  which  both  of  the  qualifiers  exist*/ 

e)  EOQ 

The  estimated  time  for  query  execution  is: 

a)  1 

b)  1 

c)  1 

d)  1 

e)  Negligible 

Total  time  =  4.5  revolutions  (note  that  this  query 
involves  two  relations) . 

In  all  of  the  queries  programmed  in  this  section,  the 
execution  time  is  independent  of  the  sizes  of  the  data  bases 
involved . 

A. 2  Queries  requiring  implicit  and/or  explicit  iterations 
Q . 7  Find  the  items  sold  by  departments  on  the  second  floor. 

The  RAP  program  is: 
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a)  MARK (A)  [ IOC: LOC. FLOOR  =  2] 


/*  Mark  departments  on  floor  2  */ 
b)  CROSS_MARK (C)  [ SALES : SALES . DEPT  =  LOC. DEPT: 

LOC. MKED (A) ] 

/*  Cross  mark  into  SALES  tuples  the  matching  */ 

/*  departments  in  marked  LOC  tuples  */ 

C)  READ  [  SALES  (ITEM)  :  SALES.  MKED  (C)  ] 

/♦Read  items  sold  by  departments  on  the  second  floor*/ 
or  * 

b*)  CROSS_MARK(BC)  [ SALES : SALES. DEPT  =  LOC. DEPT: 

LOC.  MKED  (A)] 

C1) 1)  LI  GET_FIRST_MARK (A)  [ SALES : SAL ES . ITEM  =  SALES. 
ITEM: SALES. MKED  (B)  ] 

2)  RESET (ABC)  [ SALES : SALES . MKED  (ABC)  ] 

3)  TEST  B_RAIL 

4)  BC  L1,RAIL_STAT  (B) 

/*  (1)  thru  (4)  is  a  projection  operation  */ 

/*  on  the  answer  found  in  (b)  */ 

5)  READ  [  SALES  (ITEM)  :  SALES.  MKED  (C)  ] 

/*  Read  projected  results  that  are  C-marked*/ 

d)  RESET  (C)  [SALES] 

e)  EOQ 

The  cross  marking  in  (bl)  marks  two  bits  to  save  one 
marking  revolution  needed  by  the  subsequent  projection 
operation.  It  might  be  more  economical  to  output  the  results 
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after  the  cross  marking  operation  and  have  the  duplications 
eliminated  in  the  GPC. 

The  estimated  time  for  query  execution  is: 

a)  1 

b)  1  +  NT2/k  ♦  r 2 

c)  1/2  to  rrl 

where 

NT2  is  the  number  of  T2-marked  tuples, 
k  can  be  taken  as  5, 

r2  is  the  number  of  tracks  with  T2-marked  tuples  and, 
rrl  is  the  number  of  tracks  with  BC-marked  tuples. 

If  the  program  is  written  with  (a),  (b)  ,  (c)  ,  (d)  ,  (e)  then: 

Total  time-1  =  (2.5  +  r2  +  NT2/5  ♦  (1/2  «■  rr1)/2) 
revolutions. 

A  timing  example  using  the  above  formula  will  be  given 
after  the  following  second  version  of  the  program  execution 
time.  If  the  program  includes  projection  on  BAP  rather  than 
the  cpu  of  the  GPC  then  the  execution  time  will  consist  of 
the  following: 

a)  1 

bl)  1  ♦  NT2/k  +  r2 
cl)  1)  1  *N0  ♦  r3 
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2)  1  *NU 

3)  Negligible 

4)  Negligible 

5)  1/2  to  rr2 

cl)  1 

e)  Negligible 

where 

NU  is  the  number  of  unique  tuples  that  qualify  for  the 

answer  (they  are  within  the  set  of  BC-marked  tuples  after 

the  execution  of  (b*)), 

r3  is  the  number  of  tracks  with  NU  and, 

rr2  =  r3. 

Total  time-2  =  (3.5  ♦  NT2/5  +  r2  ♦  r3  ♦  2*NU  + 

(1/2  +  rr2)/2)  revolutions. 


In  both  of  the  above  examples  read  time  is  taken  as  the 
average  of  the  two  extreme  values  which  is  a  very 
conservative  assumption.  The  block  multiplexing  scheme  of 
NAP  will  give  a  much  better  throughput  time.  The  anticipated 

track  capacity  of  a  RAP  device  was  specified  as  106  bits. 

> 

Assuming  that  a  tuple  for  the  above  example  is  1000  bits 
long  (this  figure  would  include  one  gap3  and  the  tuple 
itself)  1000  (=106/103)  tuples  can  be  stored  on  a  track.  On 
a  relation  the  repeated  combinational  domain  values  appear 
at  successive  rows  so  that  the  corresponding  tuples  are  also 
represented  as  successive  tuple  blocks  on  the  track.  The 
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following  realistic  assumptions  can  then  be  made  to  produce 
a  typical  example: 

Assume  that  NT 2  =  100  T2-marked  tuples  over  r2  =  1 

track  are  cross  marked  into  the  SALES  relation  to  produce 
1000  BC-marked  SALES  tuples  over  rrl  =  2  tracks.  Out  of 

these  BC-marked  tuples  only  NU  =  100  is  the  unique  answer 

set  to  be  found  over  rr2  =  r3  =  1  tracks.  The  overall  timing 
for  the  above  program  versions  will  be  as  follows: 

Total  time-1  =  (2.5  ♦  1  ♦  20  ♦  1.25)  =  24.75  revolutions 
for  an  iterative  program  which  processes  two  relations. 
Total  time-2  =  (3.5  +  20  +  1  +  1  +  200  ♦  0.75)  =  226.25 
revolutions. 

The  second  example  clearly  shows  that  once  an  answer 
set  is  obtained,  the  following  projection  operation  might 
better  be  carried  out  by  the  GPC  at  core  speeds.  If, 
however,  a  projection  operation  is  a  prerequisite  to  a 

subsequent  operation,  it  can  be  done  on  RAP  without  tying  up 

the  entire  device  by  using  the  RAP  concurrency  mechanism. 

Q . 8  Find  the  names  of  managers  who  manage  more  than  10 
employees. 

The  following  RAP  program  is  another  example  of  its 
ability  to  program  queries  of  the  SEQUEL  and  SQUARE 
languages.  All  the  features  of  ALPHA  can  be  handled  by  the 
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RAP  as  well.  Q.6  and  most  of  the  multi-realtional  queries 
shown  here  reflect  ALPHA-type  query  structures. 

a)  MARK  (A)  [EMP] 

/*  preprocess  for  the  GET_FIRST_MARK  */ 

b)  LI  GET_FIRST_MAPK  (B)  [EMP:  EMP.  MGR  =  EMP.  MGR: 

EMP.MKED(A)  ] 

/*  Pick  the  specified  value  of  the  tuple  and  */ 
/♦search  and  B-mark  those  with  the  same  manager*/ 

/*  another  application  of  free  variable  ♦/ 

C)  COUNT  [EMP:EMP.MKED(B) ] 

/*  Count  the  others  with  the  same  manaqer  ♦/ 

d)  BC  L2,  (REGF_1)  <  9 

/♦Skip  if  <  1 0  employees  per  manager  (first  tuple*/ 
/♦picked  up  should  also  be  implicitly  counted*/ 

e)  READ  [EMP  (MGR)  lEMP.UNMKED  (AC)  ] 

/*  Read  the  manager  */ 

f)  L2  RESET  (AB)  [  EMP:  EMP.  MKED  (AB)  ] 

/*  Clear  A  and  B  marks  */ 

g)  MARK (C)  [ EMP: EMP. UNMKED (AC)  ] 

/♦Mark  the  processed  tuples  including  the*/ 
/♦manager  so  as  not  to  reprocess  them*/ 

h)  TEST  A_RAIL 

i)  BC  LI ,RAIL_STAT (A) 

/*  Repeat  for  other  managers  and  clear  */ 

/*  marks  at  the  end  */ 
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i) 

k) 


RESET  (C)  [EMP] 
EOQ 


The  estimated  time  for  query  execution  is: 

a)  1 

b)  1*NM  ♦  r3 

c)  2*NM  (one  for  cell  execution,  one  for  SFU 
evaluation  and  next  instruction  synchronization) 

d)  Negligible 

e)  1  *NMH 

f)  1 *NM 

g)  1  *NM 

h)  Negligible 

i)  Negligible 

j)  1 

where 

NM  is  the  number  of  managers, 

NMH  is  the  number  of  qualifying  managers,  and 

r3  is  the  number  of  tracks  with  unique  set  of  managers 
which  are  picked  up  by  the  GET_FIRST_MAF.K. 

Total  time  =  (2.5  +  5*NM  +  r3  ♦  NMH)  revolutions. 

Q.9  Find  the  total  volume  of  items  of  type  A  sold  by  the 
departments  on  the  second  floor. 
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The  RAP  program  is: 


a)  MARK (A)  [ LOC: LOC. FLOOR  =  2] 

/*  Mark  second  floor  tuples  */ 

b)  CROSS_MARK  (B)  [ SALES : SALES. DEPT  =  LOC . DEP T: LOC. MKED (A)  ] 
/*  Mark  SALES  tuples  with  departments  on  */ 

/*  the  second  floor  */ 

c)  MARK (A)  [ CLASS: CLASS. TYPE  =  «A* ] 

/*  Mark  A  type  items  (note  that  A-marks  */ 

/*  were  reset  in  (b) )  */ 

d)  CRS_COND_MARK  (B[  C  ])  [  SALES :  SAL ES.  ITEM  =  CLASS.  ITEM: 
CLASS.  MKED  (A)  ] 

/*  Retain  B-marked  SALES  tuples  if  their  */ 

/*  items  are  of  A  type,  otherwise  reset  */ 

e)  SUM  [  SALES  (VOL)  :  SALES.  MKED  (B)  ] 

/*  Find  the  total  volume  of  items  of  type  A  sold  */ 

/*  by  departments  on  the  second  floor  */ 

f)  READ_REG  [  (REGF__1 )  ] 

/*  Transfer  the  result  */ 

g)  RESET  (B)  [SALES] 

/*  Clear  bits  */ 

h)  EOQ 

The  time  required  for  the  query  execution  is: 

a)  1 

b)  1  +  NT21/k  +  r21 
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c)  1 

d)  2  +  NT22/k  ♦  r22 

e)  2 

f)  Negligible 

g)  1 

h)  Negligible 

where 

NT21  is  the  number  of  A-marked  LOC  tuples  over 
r21  tracks, 

NT22  is  the  number  of  A-marked  CLASS  tuples  over 
r22  tracks. 

Total  time  =  (8.5  +  (NT21  ♦  NT22)/5  ♦  r21  ♦  r22) 
revolutions. 

In  all  of  the  iterative  type  queries  programmed  in  this 
section  it  can  be  seen  that  the  query  execution  time  is 
independent  of  the  sizes  of  the  target  relations  involved 
since  the  device  is  associative,  but  depends  linearly 
(reduced  by  k — the  cell  parallel  hardware)  on  the  sizes  of 
the  qualified  source  relations  and/or  their  number  of  unique 
domain  values. 
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APPENDIX  B 


SUMMARY  OF  INSTRUCTION  TIMINGS 

Table  1  gives  the  time  required  for  the  execution  of 
each  of  the  RAP  instructions. 


TYPE  OF  OPERATION  INSTRUCTION 

EXECUTION  TIME  IN 

NUMBER  OF  REVOLUTIONS 

UNLESS  OTHERWISE  SPECIFIED 

Retrieval  commands  MARK 

1 

RESET 

1 

READ 

Minimum=1/2  on  average, 

Maximum=Number  of  quali¬ 
fied  tracks  occupied  by 

the  relation 

READ_REG 

Negligible 

CROSS_MARK 

Depends  on  data 

CRS_COND_MARK 

Same  as  CROSS_MARK  plus  1 

GET_FIF.ST_M.ARK 

Depends  on  data 

GET_F IRST 

Same  as  GET_FIRST_MARK 

SAVE 

1 

Update  commands  ADD 

1 

SUB 

1 

MUL 

1 

DIV 

1 

Table  1-  Instruction  timing 
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TYPE  OF  OPERATION  INSTRUCTION 


REPLACE 


Set  function 


EXECUTION  TIME  IN 
NUMBER  OF  REVOLUTIONS 
UNLESS  OTHERWISE  SPECIFIED 

1 


commands 


Insertion  and  de 
letion  commands 


COUNT 

1 

♦  Fraction 

MAX 

1 

♦  Fraction 

MIN 

1 

♦  Fraction 

SUM 

1 

♦  Fraction 

AVERAGE 

2 

♦  Fraction 

DELETE 

INSERT 

1 

Minimum  =  1 ,  Maximum  =  2 

DROP  DOMAIN 

Maximum  number  of  relation 

tuples  per  track 


Data  base  crea¬ 
tion  and  destruc 


tion  commands 

DESTROY 

Fraction 

CREATE 

1 

Decision  and  trans¬ 

fer  commands 

TEST 

Negligible 

BC 

Negligible 

EOQ 

Negligible 

Table  1  -  (continued) 
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